Classified VTU activated without unique user login

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-17691	RTS-VTC 2028.00	SV-18865r1_rule	DCBP-1 ECSC-1 IAIA-1 IAIA-2	Medium

Description
There are numerous DoD policy statements that require a user of a DoD IS to identify themselves to the IS so that it can authenticate and authorize the user before being used or before service is provided. This is primarily so that accesses to, and usage of, the IS and access to DoD information can be controlled and monitored based on the user’s privileges or authorizations. These requirements range from a minimum of a user-id and password to token based two factor authentication and work in combination with security auditing to create a record of user activities that are tied to the user’s identification. VTC endpoints today do not provide any identification, authorization, or auditing capabilities with regard to their activation and use, whether stand alone or in conjunction with an authentication server. Any user can turn an endpoint on and make or receive calls. While at least one vendor’s system can be configured to require the entry of a PIN to place a call, the feature is only a call accounting feature and not a security feature. While gatekeepers and gateways provide some access control, this control only relates to access to their services. They do not play a part in endpoint activation or use of the endpoint for point-to-point calls. The International Telecommunications Union (ITU) has developed H.235, which is the security recommendation for H.323 and other H.245 based systems. This recommendation provides for user identification rather than device identification. User identification can be simple or utilize Public Key Infrastructure (PKI). The latter being the goal of the DoD PKI policy. H.235 also has the capability and purpose of negotiating encryption and key exchange. The ITU has also developed H.350. Unlike other H. series protocols, H.350 is a schema using Lightweight Directory Access Protocol (LDAP) to store directory and identity management information. The use of H.350 can improve security by providing standardized management and storage of authentication credentials, as well as multilevel authorization. The use of H.245 and H.350 in combination could be the solution to the endpoint activation and user identification deficiency currently exhibited by VTC endpoints. While it seems debatable whether a VTC endpoint is, or should be, subject to DoD access control and auditing policies, particularly in unclassified environments, there are use cases where such compliance would be beneficial to the protection of DoD information. This is particularly in cases where a VTU is located in an area where classified materials, information, and/or discussions occur because an active VTU could generate a security incident. This issue could be more of a concern if the VTU was located in a classified work area while connected to an unclassified network or network having a lower classification than the work area. Compliance would also be beneficial for VTUs in areas processing sensitive information. To protect the information discussed in the previous paragraph, the VTU should remain dormant (even while powered on) and not capable of placing or answering a call unless it is activated by a user logging onto the system.

Description

There are numerous DoD policy statements that require a user of a DoD IS to identify themselves to the IS so that it can authenticate and authorize the user before being used or before service is provided. This is primarily so that accesses to, and usage of, the IS and access to DoD information can be controlled and monitored based on the user’s privileges or authorizations. These requirements range from a minimum of a user-id and password to token based two factor authentication and work in combination with security auditing to create a record of user activities that are tied to the user’s identification. VTC endpoints today do not provide any identification, authorization, or auditing capabilities with regard to their activation and use, whether stand alone or in conjunction with an authentication server. Any user can turn an endpoint on and make or receive calls. While at least one vendor’s system can be configured to require the entry of a PIN to place a call, the feature is only a call accounting feature and not a security feature. While gatekeepers and gateways provide some access control, this control only relates to access to their services. They do not play a part in endpoint activation or use of the endpoint for point-to-point calls. The International Telecommunications Union (ITU) has developed H.235, which is the security recommendation for H.323 and other H.245 based systems. This recommendation provides for user identification rather than device identification. User identification can be simple or utilize Public Key Infrastructure (PKI). The latter being the goal of the DoD PKI policy. H.235 also has the capability and purpose of negotiating encryption and key exchange. The ITU has also developed H.350. Unlike other H. series protocols, H.350 is a schema using Lightweight Directory Access Protocol (LDAP) to store directory and identity management information. The use of H.350 can improve security by providing standardized management and storage of authentication credentials, as well as multilevel authorization. The use of H.245 and H.350 in combination could be the solution to the endpoint activation and user identification deficiency currently exhibited by VTC endpoints. While it seems debatable whether a VTC endpoint is, or should be, subject to DoD access control and auditing policies, particularly in unclassified environments, there are use cases where such compliance would be beneficial to the protection of DoD information. This is particularly in cases where a VTU is located in an area where classified materials, information, and/or discussions occur because an active VTU could generate a security incident. This issue could be more of a concern if the VTU was located in a classified work area while connected to an unclassified network or network having a lower classification than the work area. Compliance would also be beneficial for VTUs in areas processing sensitive information. To protect the information discussed in the previous paragraph, the VTU should remain dormant (even while powered on) and not capable of placing or answering a call unless it is activated by a user logging onto the system.

STIG	Date
Video Teleconference STIG	2014-02-11

Details

Check Text ( C-18961r1_chk )
[IP][ISDN]; Verify compliance with the following requirement: Ensure the VTU is not capable of placing or answering a call (i.e., is locked) unless it is activated by a user logon. Furthermore such activation will automatically deactivate after a configurable time period (typically 15 minutes) unless the VTU is actively participating in a conference. Incoming call notifications are provided while the VTU is locked so that a user may log in to activate the VTU and answer the call. Note: While requiring a user to logon to the VTU before it can be used to place and/or receive calls may detract from the VTUs “ease-of-use” and the “user experience”, (something vendors are concerned about,) the capability should exist and be usable where needed. Application of the capability could be different in various situations. This capability should be configurable. In other words, it can be turned on or off. There should be one setting to activate the requirement that a user logon to activate the VTU for general use and/or to make a call. There should be another setting to activate the requirement that a user logon to activate the VTU to answer a call. If these settings are turned on, authentication must minimally be a password that is unique to the user that is placed in CDRs. More in line with DoD policy, user-ID and password should be required as well as entry of the access into the audit log. Furthermore, the VTU should support the use of DoD PKI for user authentication. To comply with DoD access control requirements for both users and administrators, a VTU could, and in fact probably should, utilize a remote authentication server that can provide centralized management of passwords and accounts. Note: During APL testing, this is a finding in the event Unique User Identification is not supported by the VTU. If VTC endpoints are located in classified work areas or connected to a classified IP network, perform the following checks for each tested device: 1 - Attempt to initiate a call without logging in. If menu or directory access is provided and a number can be dialed, this is a finding. 2 - Interview the IAO or SA to determine the site's inactivity timeout period policy: Have the IAO or SA log onto the VTU using a unique user ID (not an admin ID) to activate the VTU. Verify VTU activation will automatically deactivate or lock, when the VTU is inactive (i.e., not active in a VTC session) in excess of the specified timeout period. This is a finding if the VTU does not require reactivation after the configured time period. 3- Verify that while a VTU is locked that an incoming call notification is provided so that the user may log onto VTC an answer the call. This is a finding if no incoming call notification is provided. Check all VTUs if possible or minimally select a random sampling of units to test. Alternately, if documentation exists indicating that the VTU operation has been verified to support these requirements via pre-deployment testing (e.g., APL testing/report), have the IAO or SA demonstrate the configuration settings on all VTUs required to implement this functionality. As an additional step, one VTU could be verified via the process defined above.

Check Text ( C-18961r1_chk )

[IP][ISDN]; Verify compliance with the following requirement:

Ensure the VTU is not capable of placing or answering a call (i.e., is locked) unless it is activated by a user logon. Furthermore such activation will automatically deactivate after a configurable time period (typically 15 minutes) unless the VTU is actively participating in a conference. Incoming call notifications are provided while the VTU is locked so that a user may log in to activate the VTU and answer the call.

Note: While requiring a user to logon to the VTU before it can be used to place and/or receive calls may detract from the VTUs “ease-of-use” and the “user experience”, (something vendors are concerned about,) the capability should exist and be usable where needed. Application of the capability could be different in various situations. This capability should be configurable. In other words, it can be turned on or off. There should be one setting to activate the requirement that a user logon to activate the VTU for general use and/or to make a call. There should be another setting to activate the requirement that a user logon to activate the VTU to answer a call. If these settings are turned on, authentication must minimally be a password that is unique to the user that is placed in CDRs. More in line with DoD policy, user-ID and password should be required as well as entry of the access into the audit log. Furthermore, the VTU should support the use of DoD PKI for user authentication. To comply with DoD access control requirements for both users and administrators, a VTU could, and in fact probably should, utilize a remote authentication server that can provide centralized management of passwords and accounts.

Note: During APL testing, this is a finding in the event Unique User Identification is not supported by the VTU.

If VTC endpoints are located in classified work areas or connected to a classified IP network, perform the following checks for each tested device:
1 - Attempt to initiate a call without logging in. If menu or directory access is provided and a number can be dialed, this is a finding.
2 - Interview the IAO or SA to determine the site's inactivity timeout period policy: Have the IAO or SA log onto the VTU using a unique user ID (not an admin ID) to activate the VTU. Verify VTU activation will automatically deactivate or lock, when the VTU is inactive (i.e., not active in a VTC session) in excess of the specified timeout period. This is a finding if the VTU does not require reactivation after the configured time period.
3- Verify that while a VTU is locked that an incoming call notification is provided so that the user may log onto VTC an answer the call. This is a finding if no incoming call notification is provided.

Check all VTUs if possible or minimally select a random sampling of units to test.

Alternately, if documentation exists indicating that the VTU operation has been verified to support these requirements via pre-deployment testing (e.g., APL testing/report), have the IAO or SA demonstrate the configuration settings on all VTUs required to implement this functionality. As an additional step, one VTU could be verified via the process defined above.

Fix Text (F-17588r1_fix)
); [IP][ISDN]; Perform the following tasks: Implement/upgrade to VTUs that support the configuration requirements described below. Configure the VTU to provide the following functionality: 1 - Configure unique (non-default/non-shared) user identities for both privileged (admin level) and non-privileged (user level) users. Provide multiple accounts as necessary in each level. Administrators should have a test user level account in addition to their admin level account. 2 - Configure the VTU such that a unique user ID is required to activate the VTU. 3 - Configure the VTU to automatically lock at the end of a specified period of inactivity. (typically 15 minutes or less). 4 - Configure the VTU to display an incoming call notification while deactivated so that a unique user ID is required to activate the VTU and answer the call.

Fix Text (F-17588r1_fix)

); [IP][ISDN]; Perform the following tasks:

Implement/upgrade to VTUs that support the configuration requirements described below.

Configure the VTU to provide the following functionality:

1 - Configure unique (non-default/non-shared) user identities for both privileged (admin level) and non-privileged (user level) users. Provide multiple accounts as necessary in each level. Administrators should have a test user level account in addition to their admin level account.
2 - Configure the VTU such that a unique user ID is required to activate the VTU.
3 - Configure the VTU to automatically lock at the end of a specified period of inactivity. (typically 15 minutes or less).
4 - Configure the VTU to display an incoming call notification while deactivated so that a unique user ID is required to activate the VTU and answer the call.